How Blitz scaled their game coaching app with lower latency and leaner operations est une start-up en pleine croissance qui fournit un coaching personnalisé pour des jeux tels que League of Legends, Valorant et Fortnite. Ils visent à aider les joueurs à devenir des légendes de League of Legends grâce à des informations en temps réel et à une analyse post-match. Lumière Pendant que les joueurs jouent, l'application fait beaucoup de travail. Il capture les données des matchs en direct, les analyse rapidement et les utilise pour des surplays d'écran de jeu en temps réel ainsi que pour un coaching post-jeu personnalisé.Le guide est basé sur l'activité de jeu actuelle et historique de chaque joueur, ainsi que sur les données collectées sur des milliards de matchs impliquant des centaines de millions d'utilisateurs. Grâce à la prise de conscience croissante des statistiques populaires de Blitz et de l'application de coaching de jeu, leur base d'utilisateurs en croissance constante a poussé leur architecture originale basée sur Postgres et Elixir à ses limites. Afin de fournir une faible latence, une haute disponibilité et une évolutivité horizontale à leur base d’utilisateurs en pleine croissance, ils : TL;DR Migration des services de backend d'Elixir à Rust. Remplacer Postgres par ScyllaDB Cloud. Il a considérablement réduit son empreinte. Supprimer leur cluster Riak. Remplacement du traitement de la queue par le traitement en temps réel. Infrastructure consolidée allant de plus d'une centaine de noyaux de microservices à quatre n4-4 nœuds Google Cloud standard (plus une petite instance Redis pour le cache de bord) En bonus supplémentaire, ces changements ont fini par réduire les coûts d’infrastructure de Blitz et réduire la charge de la base de données sur leur personnel d’ingénierie. Blitz arrière-plan Comme l’explique Naveed Khan (chef de l’ingénierie de Blitz), « nous recueillons beaucoup de données auprès des éditeurs de jeux et pendant le gameplay. par exemple, si vous jouez à League of Legends, nous utilisons l’API de Riot pour extraire des données de match, et si vous installez notre application, nous surveillons également le gameplay en temps réel. Scaling Passé Postgres Un élément clé du système de Blitz est l’API Playstyles, qui analyse les données pré-jeu pour les coéquipiers et les adversaires. Ce processus intensif évalue jusqu’à 20 matchs par joueur et s’effectue neuf fois par match (une fois pour chaque joueur du match). L’équipe a réformé stratégiquement et consolidé de nombreux microservices pour améliorer les performances. Mais le volume de données est resté intense. Selon Brian Morin (Ingénieur principal du backend chez Blitz), « trouver une solution de base de données capable de gérer ce volume de requête a été crucial. » À l’origine, ils ont utilisé Postgres, ce qui leur a servi très tôt. Cependant, à mesure que leurs charges de travail pesant sur l’écriture ont augmenté, la complexité opérationnelle et les coûts sur Google Cloud ont considérablement augmenté. De plus, l’évolutivité de Postgres est devenue assez complexe. Naveed a partagé: «Nous avons essayé toutes sortes de choses pour évoluer.Nous avons construit plusieurs services autour de Postgres pour obtenir l’échelle dont nous avions besoin: un cluster Redis, un cluster Riak et des files d’attente d’Elixir Oban qui s’envolaient de temps en temps. Au fur et à mesure que les start-ups s’agrandissent, elles passent souvent de « simplement utiliser Postgres » à « simplement utiliser NoSQL ». L’équipe de Blitz envisageait de passer à MongoDB, mais finit par l’exclure. « Nous avions beaucoup d’expérience MongoDB dans l’équipe et certains d’entre nous l’aimaient vraiment. Cela créerait une barrière pour leur charge de travail spécifique et leur croissance attendue. L'architecture primaire et secondaire de MongoDB Les tests ont montré qu’il répondrait à leurs besoins de latence, donc ils ont effectué le (re)modélisation des données requises et migré quelques jeux plus petits de Postgres à RocksDB. Cependant, ils ont finalement décidé contre RocksDB en raison de préoccupations d’échelle et de haute disponibilité. « Sur la base des données disponibles de nos tests, il était clair que RocksDB ne serait pas en mesure de gérer la charge de nos jeux plus grands – et nous ne pouvions pas risquer d’évoluer verticalement une seule instance, puis d’avoir cette instance tomber », a expliqué Naveed. Pourquoi ScyllaDB Un de leurs ingénieurs de backend a suggéré ScyllaDB, de sorte qu'ils ont atteint et a exécuté une preuve de concept. Ils étaient principalement à la recherche d'une solution qui peut gérer le débit d'écriture, les échelles horizontalement, et fournit une haute disponibilité. Ils l'ont d'abord testé sur leur propre matériel, puis ont déménagé vers ScyllaDB Cloud. Par Naveed, "Le coût était assez proche de l'auto-hébergement, et nous avons obtenu la gestion complète gratuitement, donc c'était un non-brainer. Nous avons maintenant un cluster Redis considérablement réduit, plus nous avons éliminé le cluster Riak et les dépendances d'Oban. Du point de vue des performances, le changement a atteint leur objectif d’équilibrer l’expérience utilisateur ... et de simplifier la vie de leurs équipes d’ingénierie. Brian a ajouté: «ScyllaDB s’est avéré exceptionnel, offrant des performances robustes avec une capacité d’épargne après optimisation. Nos produits League atteignent des sommets d’environ 5k op/sec avec le cluster signalant moins de 20% de charge. Notre plus grande contrainte a été l’utilisation du disque, que nous avons mis en place plusieurs mises à jour pour atténuer. Le nouveau système peut maintenant retourner des résultats immédiatement au lieu de s’appuyer sur des données cachées, fournissant des informations plus à jour sur d’autres joueurs et même identifiant des coéquipiers fréquents High-Level Architecture of Blitz Server with Rust and ScyllaDB Réécrire les services Elixir dans Rust Dans le cadre d’une révision majeure du backend, l’équipe de Blitz a commencé à repenser l’ensemble de leur infrastructure – au-delà du changement précédemment décrit de Postgres vers le ScyllaDB hautes performances et distribué. En plus de cette migration de bases de données, ils ont également choisi de mettre en place leurs services basés sur Elixir en faveur d’un langage plus moderne. Après une évaluation minutieuse, Rust est apparu comme le choix évident. «Elixir est génial et a bien servi son but», a expliqué Naveed. «Mais nous voulions aller vers quelque chose avec une adoption plus large et un écosystème plus fort au niveau des systèmes. Maintenant que le premier lot de services de réécriture de Rust est en production, Naveed et l’équipe ne regardent pas en arrière : « Rust est fantastique. Il est rapide, et le compilateur vous oblige à écrire du code sécurisé par la mémoire à l’avance au lieu de déboguer les problèmes de collecte de déchets plus tard.
